1. Field of the Invention
The present invention generally relates to technologies for sending and receiving network topology information including redundancy information between nodes using a routing protocol for generalized multiprotocol label switching (GMPLS).
2. Description of the Related Art
A technology called multiprotocol label switching (MPLS), in which IP packets are routed based on labels, has become widely used. Also, a technology called generalized multiprotocol label switching (GMPLS) is drawing attention. In GMPLS, the idea of “labels” used for routing IP packets in MPLS is generalized and adapted for other networking technologies such as time division multiplexing (TDM) and wavelength division multiplexing (WDM) (i.e. TDM layer and wavelength path layer).
In MPLS and GMPLS, a label switched path (LSP) indicating a path or a route in a network is set up by referring to a label table. Normally, in MPLS and GMPLS, a source node calculates a route to a destination node and sets up an LSP for the calculated route using a signaling protocol such as the resource reservation protocol-traffic engineering (RSVP-TE).
Route calculation in MPLS and GMPLS is performed based on network topology information obtained by nodes using a routing protocol such as the open shortest path first-traffic engineering (OSPF-TE). OSPF-TE is used for traffic engineering in MPLS and is developed by extending OSPF used for IP networks. Also, extensions to OSPF-TE used for GMPLS are defined in RFC 4203.
In OSPF-TE, each node advertises link information retained in itself to other nodes by opaque link state advertisement (opaque LSA; RFC 2370 and RFC 3630), and each node creates a topology information database of the entire network based on link information from other nodes. In opaque LSA, link information is advertised in a format called TLV (type/length/value). There are generally two types of TLVs: the router address TLV and the link TLV. In the present application, the link TLV is mainly discussed. A link TLV may include sub-TLVs (RFC 3630 and RFC 4203) (sub-TLVs may also be called sub-frames in the present application). FIG. 1 is a drawing illustrating a format of a TLV (RFC 3630). FIG. 2 is a drawing illustrating a TLV including sub-TLVs.
There are 16 types of sub-TLVs: types 1 through 9 for traffic engineering in MPLS (RFC 3630), and types 11 through 16 for GMPLS (RFC 4203).
Of the 16 types of sub-TLVs, sub-TLV type 7 (may also be called a reservable bandwidth sub-frame) is assigned to “Maximum Reservable Bandwidth” and is used to advertise a maximum reservable bandwidth (reservable bandwidth information) of a link to other nodes. Sub-TLV type 14 (may also be called a protection type sub-frame) is assigned to “Link Protection Type” and is used to advertise the reliability of a link. Sub-TLV type 14 contains one of the values as shown in FIG. 3 (RFC 4203).
Meanings of some of the values are described below. Explanations of other values can also be found in RFC 4202. 0x01Extra Traffic means that the link is protecting another link or links. LSPs on a link of this type will be lost if any of the links it is protecting fails. 0x02 Unprotected means that there is no other link protecting this link. LSPs on a link of this type will be lost if the link fails. 0x20 Enhanced means that there are two or more dedicated disjoint links for protecting this link. For example, it indicates that a 4-fiber bidirectional line switched ring (4-fiber BLSR) is being used to protect this link. Patent document 1 discloses a technology for setting up a path according to GMPLS.
[Patent document 1] Japanese Patent Application Publication No. 2006-135945
[Non-patent document 1] RFC2370, The OSPF Opaque LSA Option, July 1998
[Non-patent document 2] RFC3630, Traffic Engineering (TE) Extensions to OSPF Version 2, September 2003
[Non-patent document 3] RFC4202, Routing Extensions in Support of Generalized Multi-protocol Label Switching (GMPLS), October 2005
[Non-patent document 4] RFC4203, OSPF Extensions in Support of Generalized Multi-protocol Label Switching (GMPLS), October 2005
As described above, a sub-TLV for advertising reliability of a link is defined in OSPF-TE for GMPLS. However, there is one problem in using a synchronous optical network/synchronous digital hierarchy (SONET/SDH) path in a BLSR as a link for setting up an LSP. In the descriptions below, a SONET/SDH path is called a “line” to distinguish it from a path (LSP) set up on a link (TE link).
In a BLSR, a SONET/SDH line may be used as a normal line, a protection channel access (PCA) line, or a non-preemptible unprotected traffic (NUT) line. A normal line has a backup line and if the normal line fails, traffic is switched to the backup line. A PCA line is used as a backup line. When an active line being protected by the PCA line fails, the traffic currently flowing through the PCA line is stopped. A NUT line is an active line having no backup line. When the NUT line fails, the traffic flowing through the NUT line is lost.
When using a SONET/SDH line in a BLSR as a link for an LSP, for example, a normal line corresponds to an “Enhanced” link defined by RFC 4202, a PCA line corresponds to an “Extra Traffic” link, and a NUT line corresponds to an “Unprotected” link.
Multiple SONET/SDH lines can be set up in a link between nodes, and each of the SONET/SDH lines may be assigned to a normal line, a PCA line, or a NUT line of a BLSR. With the current routing protocol standards for GMPLS, however, it is not possible to advertise the protection type regarding redundancy for each of the SONET/SDH lines in a link.
FIG. 4 is a drawing illustrating an exemplary network including a BLSR. In the exemplary network shown in FIG. 4, a BLSR is formed by a ring connecting nodes B, D, D, and E. No backup lines are provided for lines (links) between nodes A and B, nodes A and M, nodes M and Z, and nodes Z and D. Texts provided on the lines between nodes indicate their bandwidths.
FIG. 5 is a table showing exemplary topology information retained in each node according to the current OSPF-TE. The exemplary topology information includes only parameters necessary for the descriptions given below.
With the current OSPF-TE, as described above, each node can advertise only one protection type and one type of reservable bandwidth information for each link. Therefore, as shown in FIG. 5, the exemplary topology information includes only one protection type and one type of reservable bandwidth information for each link. For example, the exemplary topology information includes only a protection type “Enhanced” and reservable bandwidth information “12ch” (which indicates 12 channels are available) for the link between nodes B and C. In the present application, a “channel” indicates the smallest unit of bandwidth of a SONET/SDH line.
In the network shown in FIG. 4, it is possible to set up an LSP having high reliability by referring to the connection information, the protection types, and the reservable bandwidth information shown in FIG. 5. For example, when setting up an LSP from node A to node Z, an LSP A-B-C-D-Z or A-B-E-D-Z, which goes through the BLSR, may be selected according to the topology information shown in FIG. 5.
However, with the topology information shown in FIG. 5, for example, it is not possible to set up a low-cost LSP using PCA lines since only one protection type is provided for each link. Also, although it is necessary to use the same type of synchronous transport signal (STS) channels of SONET (or the same type of synchronous transport module (STM) channels of SDH) when setting up an LSP on normal lines in a BLSR, it is not possible to advertise STS (or STM) channel information with the current GMPLS standards. In other words, a node cannot distinguish types of STS channels in a link when calculating a route to set up an LSP. Therefore, with the current OSPF-TE or the MPLS/GMPLS standards, it is not possible to select the same type of STS channels for an LSP to be set up on normal lines at the route calculation stage, and it is only possible to select the same type of STS channels when setting up the LSP by using a signaling protocol.
The above problem may be solved by defining an original TLV having a proprietary type number and by advertising redundancy information using the original TLV. However, if the proprietary type number is assigned to a new TLV type in a standard in the future, the original TLV becomes unusable. If different types of TLVs are assigned to the same type number, it causes a malfunction of a network apparatus. Therefore, defining an original TLV is not an appropriate way to solve the problem.
The above problem applies not only to a case where an LSP is set up in a network including a BLSR but also to a case where an LSP is set up in a network having any type of redundant configuration.